1. Field of the Invention
The present invention relates generally to the computerized delivery of data from a server object to a client object, and more specifically to a method and system for sequentially delivering video data to network clients while adhering to the hypertext transfer protocol.
2. Related Art
With the increased popularity of the Internet, a strong need has developed to provide a method and system for delivering video data across the World Wide Web. Developing such technology is difficult, however, because the hypertext transfer protocol, which defines the standard for delivering Web data, does not provide a protocol for the sequential delivery of images. As a result, a number of proprietary protocols have been developed. But from these, no single protocol has emerged as the de facto standard.
The reasons for this are many, but perhaps most important is that the computers connected to the Web subscribe to a variety of platforms. These differing platforms may include different operating systems, such as those promulgated and trademarked by UNIX, SUN MICROSYSTEMS (e.g., SOLARIS), IBM (e.g., OS/2), MICROSOFT (e.g., WINDOWS NT, WINDOWS 95, WINDOWS 3.1) and APPLE (e.g., MacOS, OS8). These operating systems have varying application program interfaces. Thus, video delivery software must be individually tailored to each API to run on the associated operating systemxe2x80x94a costly and time consuming process.
Another impediment to the development of a consistent method of video delivery is that the computers connected to the Web vary greatly in terms of processing power. This variance is problematic because a protocol that works well with powerful computers may yield unsatisfactory results with computers having more limited power.
The prior art has not even attempted to create a universal delivery system. Instead, the most common approaches cater to computers that have substantial processing power or that are run under the more common operating systems. One such approach requires the installation of a xe2x80x9cplug-in.xe2x80x9d This is illustrated in FIG. 1, which depicts a client computer 100 connected to a server computer 102 over the Internet 104. As shown, the computers connect to the Internet 104 via modems 106, although those skilled in the art will recognize that other forms of communication are possible, such as wireless hookups.
In addition to the modem 106, the client computer 100 has the standard array of components: a central processing unit 108; a user interface 110, which typically consists of a keyboard, a mouse, and a monitor; a primary memory 112, such as a random access memory, for program execution; and a secondary memory 114, such as a disk, for storing programs and data that are not immediately needed for execution. As illustrated, the server computer 102 contains the same array of basic computer components 108, 110, 114, with the exception of the user interface 110. Those skilled in the art will appreciate, however, that the server computer 102 could also possess such an interface.
The client and the server computers 100, 102 also each have an operating system 118 that is stored in the secondary memory 114 and loaded into the primary memory 112 to manage the respective computer""s resources. For example, with respect to the client computer 100, the operating system 118 provides an application program interface that allows programs, such as the browser 120, to interact with the modem 106 so that communication may be made with the server computer 102. Similarly, the programs of the server computer 102, such as the proprietary video server 122, access the server computer""s operating system 118 to communicate to the client computer 100.
The plug-in method requires the server computer 102 to install the proprietary video server 122 and requires the client computer 100 to install a proprietary plug-in 124. The proprietary server 122 retrieves video data 126 from the disk 114 of the server computer 102 and downloads it to the client computer 100. The plug-in 124 is then invoked on the client side to display the downloaded data 128. Plug-ins can be installed as stand alone programs, or, as shown in FIG. 1, can be installed xe2x80x9cin-linexe2x80x9d in a web browser 120. In advanced systems, the downloaded data 128 will be displayed using a process known as xe2x80x9cstreaming,xe2x80x9d which is a compression and buffering technology that allows the client computer 100 to display data in near real-time. If the server 102 is incapable of streaming data, the plug-in 124 displays the data 128 after it has been downloaded.
While the plug-in technique provides a capable method of delivering video data in certain environments, the technique has several disadvantages First, it requires the purchase of the proprietary server 122 and associated development tools to even create the video data 126. And because this data 126 is designed for use with a proprietary plug-in 124, it often does not conform to formats that are viewable under the hypertext transfer protocol. Thus, only those who have purchased the plug-in 124 can view the created video 126, 128. This purchase cost frequently represents more than a one-time investment because the proprietary protocol may require constant upgrades. Also, a newly emerging protocol may displace an old one, requiring the user to start anew.
Even if purchase costs do not represent a significant impediment to broad deployment of the media, other obstacles do. The installation of the plug-in 124 is often a complex procedure, and one made particularly difficult if the data is to be delivered through a secure gateway, sometimes referred to as a xe2x80x9cfirewall.xe2x80x9d Plug-ins also frequently require an elaborate infrastructure, such as repeaters, and can require more processing power than the client computer 100 can deliver. When this problem arises, the results can be merely unsatisfactory or nearly catastrophic. For example, when the modem 106 provides a limited bandwidth, the time required to download the video data may be so great that the user will abort the process in frustration. When the CPU 108 operates at a relatively low processing speed, or when the client computer 100 contains limited RAM 112, the video may appear as a disjointed sequence of images or may be displayed so slowly that the client computer 100 appears to have ceased its processing.
Attempts to improve upon the plug-in system have been only marginally successful. For example, one attempt has the client object sequentially accessing image files stored on the server""s disk. In one version of this approach, the client object requests the image files at a rate independent of that which the server creates them. In this scheme, the client computer could request image files at a rate of two frames per second while the server computer retrieved images from a camera and stored them to disk at a rate of three frames per second. It was hoped that this rate decoupling would provide for efficient delivery because the client could control its use of network bandwidth. Unfortunately, the technique introduced fatal timing errors: Because the client requested data at a rate independent of the server, requests for image files occurred while the data server was updating the needed image, e.g., when the server was storing or retrieving images to and from the disk. As a result, the data server would return a xe2x80x9cFile not Foundxe2x80x9d message that caused some servers to permanently suspend the exchange of data. In colloquial terms, this is known as xe2x80x9ccrashingxe2x80x9d and, next to the destruction of data, is the most undesirable result that a communication error can produce.
To avoid such errors, some methods deliver video data using casting technologies, such as the xe2x80x9cPUSHxe2x80x9d hypertext transfer protocol extension that is proprietary to NETSCAPE. This extension allows for the delivery of data across a network channel at a speed dictated by server software. While this can be efficient for some systems, it is inadequate for those with limited processing power because the client computer cannot reduce the rate at which it must receive the data. This can be particularly problematic in cases where the receiving computer is connected to a local area network. In this case, the receiving computer can monopolize the network""s bandwidth, which can cause other computers connected to the LAN to experience delays when accessing network resources. The PUSH approach is also not broadly deployable because, like the plug-in approach, it requires the purchase of proprietary software, i.e., proprietary server software. The deployability is further limited by the fact that PUSH and other webcasting technologies are proprietary HTTP extensions. As such, they are not supported by all web browsers, and therefore some browsers are simply unable to receive xe2x80x9cpushedxe2x80x9d data.
Thus, there has been a long standing need for technology that can reliably deliver video data to client computers that operate on differing platforms and have varying degrees of processing power. There is also a compelling need to deliver the data using a manner that minimizes investments in proprietary software. The present invention satisfies these needs.
Embodiments of the invention deliver video data from a server object to numerous client objects without deviating from the standards set by the hypertext transfer protocol. These embodiments are therefore widely deployable because they do not require the client objects to install proprietary software. This deployability is further enhanced because the embodiments allow the client objects to control their use of network bandwidth by defining their respective data delivery rates. Thus, even client computers with limited processing power can efficiently utilize the invention.
One aspect of one of these embodiments is the decoupling of the client objects"" data delivery rates from the server object""s data collection rate. That is, while the server object delivers data at the rates requested by the client objects, it retrieves data at a rate independent from those delivery rates. By maintaining an inventory of the undelivered data in random access memory, the server object can quickly deliver the data to clients that are requesting it at differing rates.
An embodiment of the invention utilizes a servlet to extend the data delivery capabilities of a server computer. Client objects request to view data by accessing a Uniform Resource Locator that is aliased to the servlet. Because this URL is accessible to the client objects regardless of whether the servlet is retrieving new data or otherwise maintaining the undelivered data inventory, the invention provides for more reliable delivery than was before possible.